Development of transformation applications involves multiple players and roles. On one hand, high level transformation scenarios are typically designed by business analysts. On the other hand, application implementation, with technical requirements such as performance, is typically handled by highly specialized application programmers or developers. These two types of players have diverse backgrounds, different perspectives of the problem domain, and often times very different programming skills. Their responsibilities are different, but they also must communicate with each other and work together to produce an efficient, scalable and maintainable transformation system.
An environment based exclusively on visual transformation methods can provide all benefits associated with visual programming, such as ease of use. Transformation modules developed in this way can take advantage of some existing language-based artifacts under specific conditions. However, language based artifacts cannot take advantage of the visually developed artifacts. There is no round trip since visual tools produce proprietary formatted artifacts that are not accessible to programming languages in the public domain.
When a transformation system is developed using visual tools, it is usually easier to prototype, but it is not optimal when the transformation load increases due to the inherent properties of visual programming. Visual programming targets fairly coarse grained transformations. On the other hand, language-based transformations scale very well from a performance point since optimizations can be used at a very fine grain. However, it is harder to maintain as the complexity of the tool increases, and even experienced developers will need more time to ensure system integrity, since the effects of the change are harder to predict. There is a trade-off between these two factors when we consider the two approaches in transformation of the data structures.
These input data structures represent different kinds of information stored in various storage and transmission formats, which describe the domain in which the transformation operates. For instance, the transformation domain for SQL (Structured Query Language) is Relational Database (RDB) tables and columns. The domain for the EJB (Enterprise Java™ Beans) mapping tool in IBM WebSphere® Studio Advanced Developer includes EJB fields and RDB tables and columns. The transformation domain for TIBCO Software's mapping tool, BEA System's eLink™ family of tools, and IBM WebSphere MQ Integrator includes messages and RDB tables and columns.
Traditionally, there have been two different approaches to perform data transformation. These approaches have proven to be mutually exclusive in usage. The different approaches include either visual based tools or language based tools. Language based tools were used to perform data transformations since a programming languages can be exploited to achieve highly complex and efficient transformations. It was observed over a period of time that a significant proportion of such data transformations are straightforward assignment mappings from one field to the other. This led to the development of visual tools to make this process simpler and quicker to achieve for the most part. However, some complex scenarios are difficult or not possible to achieve using these visual tools alone. This is because a visual tool is designed for ease of use and higher level analysis, not for greatest optimization. Therefore, some of the optimizations that are possible using language based transformation modules are not feasible when using a graphical engine to generate the transformation modules used to perform the transformations of the data structures. There are proponents for each approach leading to solutions that used one approach or the other.